System and method for using acoustic digital signature generator as oracle

ABSTRACT

A hand-held sonic token can be used as a pseudorandom oracle for a requesting application, which can generate a challenge that is sent to the token. The user of the token decides whether to allow the token to function as an oracle, and if so, the user causes the token to digitally sign the challenge and send it back to the requesting application, for use of the digitally signed challenge as an encryption key. After encryption the requesting application deletes the signed challenge, with subsequent decryption essentially following the encryption process.

CLAIM OF PRIORITY UNDER 35 U.S.C. §120

The present application for patent is a continuation of patentapplication Ser. No. 10/171,960 entitled “SYSTEM AND METHOD FOR USINGACOUSTIC DIGITAL SIGNATURE GENERATOR AS ORACLE” filed Jun. 13, 2002,pending, and assigned to the assignee hereof and hereby expresslyincorporated by reference herein.

I. FIELD OF THE INVENTION

The present invention relates generally to pseudorandom oracles.

II. BACKGROUND OF THE INVENTION

The above-identified patent applications disclose hand-held sonic-based“tokens” that a person can manipulate to transmit an acoustic signalrepresenting secret information to a device, referred to as an“authenticator”, “verifier”, or “receiver”, to authenticate the personbased on the signal. As recognized in those applications, the advantageof sonic-based tokens is that a large installed infrastructure alreadyexists to receive and transmit sound and electronic signals derived fromsound. Specifically, the global telephone system exists to transmit datarepresentative of acoustic information, and apart from telephones manycomputing devices that are now linked by this same system (as embodiedin the Internet) have microphones and speakers (or can easily bemodified to have them).

As recognized herein, sonic tokens have the advantage of transmittingthe private information on the token in a fashion that prevents thereceiver from knowing the private information without a confidentialkey. Specifically, the above-referenced applications disclose sonictokens that digitally sign a message using private key/publicprinciples. More specifically, the sonic tokens digitally sign a messageby combining the message with secret information (a private key) andwith a pseudorandom number (PN) to render a signed message that can beverified as authentic only by an entity possessing the public key thatcorresponds to the private key.

As further recognized herein, the above-discussed properties of sonictokens render them suitable for use as pseudorandom oracles forencryption purposes. More particularly, the present invention recognizesthat if an application requires a relatively strong encryption key, itselectively can be granted access to the token by a user of the token toobtain, for use as an encryption key, the product of the secretinformation in the token, but not the secret information itself, therebykeeping it secure.

SUMMARY OF THE INVENTION

A method is disclosed for essentially converting an easy to rememberchallenge to a pseudorandom encryption key using a hand-held sonic tokenas a pseudorandom oracle. The pseudorandom encryption key that isgenerated by the sonic token is a relatively strong key that isdifficult for unauthorized parties to violate.

Accordingly, a method for encryption includes generating a challenge,and acoustically sending the challenge to a portable token. The methodfurther includes deciding whether to allow the token to function as apseudorandom oracle, and if so, causing the token to digitally sign thechallenge to render a signed challenge. The signed challenge isacoustically transmitted for use thereof to encrypt data.

In a preferred, non-limiting embodiment, the challenge is generated by arequesting application which encrypts data using the signed challenge.If desired, the challenge may be displayed in human readable form tohelp a user decide whether to allow the token to be used as apseudorandom oracle.

In exemplary non-limiting embodiments, the token digitally signs thechallenge at least in part by combining the challenge with a privatekey. The private key can be a secret and can have a corresponding publickey.

If desired, the signed challenge can be generated using a process thatalways renders the same signed challenge when presented with the samechallenge. For instance, the token can digitally sign the challenge bycombining the challenge with the private key and with a pseudorandomnumber (PN), and when a challenge is signed, the PN can be stored forreuse upon a second receipt of the same challenge for, e.g., decryptionpurposes.

In another aspect, a system for encryption includes a requestingapplication transmitting a challenge to a token using a wirelesscommunication path. A token receives the challenge and digitally signsit with a private key to render a signed challenge. The token thentransmits the signed challenge to the requesting application using awireless communication path, so that the requesting application can usethe signed challenge to encrypt data.

In yet another aspect, an encryption system includes acoustic means fortransmitting a challenge from a requesting application, and means forreceiving the challenge and generating a signed challenge in response.Acoustic means are provided for transmitting the signed challenge to therequesting application. Means are also provided for encrypting dataassociated with the requesting application using the signed challenge.

The details of the present invention, both as to its structure andoperation, can best be understood in reference to the accompanyingdrawings, in which like reference numerals refer to like parts, and inwhich:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the present system;

FIG. 2 is a flow chart of the encryption logic; and

FIG. 3 is a flow chart of the decryption logic.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring initially to FIG. 1, a system is shown, generally designated10, that includes a portable hand-held token 12 that can be configuredas a key fob or other small device. The present invention, however,applies to other token configurations, such as mobile communicationstations including laptop computers, wireless handsets or telephones,data transceivers, or paging and position determination receivers thatcan be hand-held or portable as in vehicle-mounted (including cars,trucks, boats, planes, trains), as desired. Wireless communicationdevices are also sometimes referred to as user terminals, mobilestations, mobile units, subscriber units, mobile radios orradiotelephones, wireless units, or simply as “users” and “mobiles” insome communication systems.

In any case, the preferred token 12 includes a visual display 14 and anelectronic data store 16. Also, the token 12 can include a pseudorandomnumber (PN) generator 18. A token microprocessor 20 accesses the PNgenerator 18 and data store 16, and can cause the display 14 to presentalpha-numeric or graphical information that a user can read or hear.

As shown in FIG. 1, the token microprocessor 20 can receive electronicsignals from a microphone 22, which generates the electronic signals bytransforming received sound waves 24 received by the microphone 22.Also, the token microprocessor 20 can send electronic signals to aspeaker 26, which transforms the electronic signals to transmitted soundsignals 28. As disclosed further below, the received sound signals 24might represent a challenge (e.g., a request for encryption key) from auser component 30, and the transmitted sound signals 28 might representa signed challenge (e.g., the requested encryption key). While anacoustic wireless communication is preferred, other wireless paths,e.g., rf paths, might be used.

The user component 30 can be, e.g., a computer that includes arequesting microprocessor 32 which executes a software-implemented userapplication 34. The user application 34 can be, e.g., a word processingapplication or other document-generating or more generallydata-generating application that might wish to encrypt the generateddata with a relatively strong encryption key. In any case, the usercomponent 30 can include a speaker 36 for transmitting an acousticrepresentation of a challenge and a microphone 38 for receiving anacoustic representation of the response. Both the speaker 36 andmicrophone 38 communicate with the requesting microprocessor 32.

In accordance with private key/public key principles known in the artand set forth in, e.g., the National Institute for Standards andTechnology (NIST) Federal Information Processing Standards Publication186-2, January, 2000, the signature algorithm in the token 12 (executedby the token microprocessor 20) can combine a private key with a messageto be signed and with a random number “k” from the PN generator 18 torender a digital signature which is a random pair (r,s). Preferably, thetoken microprocessor 20 executes the signature algorithm upon receipt ofactivation signals from, e.g., one or more activation elements 40 suchas toggle switches, voice activation devices, or pushbuttons. It is tobe understood that the token microprocessor 20 can include a digitalprocessor proper as well as necessary clocks, analog to digitalconversion circuitry, and digital to analog conversion circuitry knownin the art.

The token microprocessor 20 accesses the data store 16, such that whenmultiple activation elements 40 are used, one or more can be associatedwith a respective private key in the store 16. In addition to one ormore private keys of private key/public key pairs, the data store 16 mayhold public key IDs, and if desired PNs that have already been generatedand used to sign challenges, along with a correlation of the PNs to thechallenges, in accordance with one non-limiting exemplary embodimentdisclosed below.

FIG. 2 shows the encryption logic of the present invention. Commencingat block 42, a challenge (e.g., an easy to remember challenge such asthe word “password”) is generated by, e.g., the user application 34 andis sent by the user component 30 to the token 12 using the communicationpathway discussed above in reference to FIG. 1. If desired, at block 44the token 12 can display the challenge and, if desired, the source ofthe challenge in human readable form on the display 14, so that a usermay decide, at decision diamond 46, whether to allow the token 12 tofunction as a pseudorandom oracle. If the user decides against allowingthe application 34 to access the token 12 for oracle purposes, the logicends at state 48.

On the other hand, if the user decides to allow the token 12 to functionas an oracle, the user can so indicate by, e.g., manipulating theactivation element 40. The logic then proceeds from decision diamond 46to block 50, wherein the token digitally signs the challenge to render asigned challenge. In some preferred, non-limiting embodiments, the tokenuses a signing process that always renders the same signed challengewhen presented with the same challenge. For instance, the token 12 mightcombine the challenge with a private key in the data store 16 but notwith a PN from the PN generator 18. Or, the conventional private keyprotocol might be followed, wherein the signed challenge is generated bycombining the challenge with both the private key and with a PN, butwith the PN subsequently being stored in the data store 16 along with acorrelation of the PN to the particular challenge with which it wasused, for purposes to be shortly disclosed.

Moving to block 52, the token 12 sends the signed challenge to the usercomponent 30 using the communication paths disclosed above for use ofthe signed challenge as an encryption key by the user application 34 toencrypt data at block 54 using, e.g., DES encryption principles known inthe art. Preferably, the application then proceeds to block 56 to deletethe signed challenge from its memory and from any peripheral storagedevices (e.g., hard disk drives) associated with the user component 30on which the signed challenge might have been stored.

When it is desired to decrypt the data, the logic of FIG. 3 is invoked.Commencing at block 58, the same challenge that was used in FIG. 2 issent by the user component 30 to the token 12. If desired, at block 60the token 12 can display the challenge in human readable form on thedisplay 14, so that a user may decide, at decision diamond 62, whetherto allow the token 12 to function as a pseudorandom oracle fordecryption purposes. If the user decides against this, the logic ends atstate 64. Otherwise, the logic proceeds to block 66, wherein the tokendigitally signs the challenge to render a signed challenge. In theabove-mentioned preferred, non-limiting embodiments wherein it isdesired that the token always generates the same signed challenge whenpresented with the same input challenge, the token can, e.g., regeneratethe same signed challenge as was generated for encryption using asigning process that does not require a PN, or it can regenerate thesame signed challenge using conventional private key protocol, with thefollowing exception. The PN that was used to generate the signedchallenge during encryption and that was subsequently stored in the datastore 16 (along with a correlation of the challenge) can be retrieved atblock 66 based on the challenge and then combined with the challenge andthe private key to render the signed challenge.

Moving to block 68, the token 12 sends the signed challenge to the usercomponent 30 for use of the signed challenge by the user application 34to decrypt data at block 70. Preferably, the application then proceedsto block 72 to delete the signed challenge from its memory and from anyperipheral storage devices (e.g., hard disk drives) associated with theuser component 30 on which the signed challenge might have been stored.

While the particular SYSTEM AND METHOD FOR USING ACOUSTIC DIGITALSIGNATURE GENERATOR AS ORACLE as herein shown and described in detail isfully capable of attaining the above-described objects of the invention,it is to be understood that it is the presently preferred embodiment ofthe present invention and is thus representative of the subject matterwhich is broadly contemplated by the present invention, that the scopeof the present invention fully encompasses other embodiments which maybecome obvious to those skilled in the art, and that the scope of thepresent invention is accordingly to be limited by nothing other than theappended claims, in which reference to an element in the singular is notintended to mean “one and only one” unless explicitly so stated, butrather “one or more”. All structural and functional equivalents to theelements of the above-described preferred embodiment that are known orlater come to be known to those of ordinary skill in the art areexpressly incorporated herein by reference and are intended to beencompassed by the present claims. Moreover, it is not necessary for adevice or method to address each and every problem sought to be solvedby the present invention, for it to be encompassed by the presentclaims. Furthermore, no element, component, or method step in thepresent disclosure is intended to be dedicated to the public regardlessof whether the element, component, or method step is explicitly recitedin the claims. No claim element herein is to be construed under theprovisions of 35 U.S.C. § 112, sixth paragraph, unless the element isexpressly recited using the phrase “means for” or, in the case of amethod claim, the element is recited as a “step” instead of an “act”.

1. A method for use in a token, comprising: receiving sound signalsrepresenting a challenge; displaying a source of the challenge in humanreadable form.
 2. The method of claim 1 further comprising: digitallysigning the challenge to render a signed challenge
 3. The method ofclaim 2, wherein digitally signing the challenge comprises: using asigning process that always renders the same signed challenge whenpresented with the same challenge.
 4. The method of claim 2, whereindigitally signing the challenge comprises: combining the challenge witha private key.
 5. The method of claim 2, wherein digitally signing thechallenge comprises: combining the challenge with a private key and witha PN; and subsequently storing the PN along with a correlation of the PNto the challenge.
 6. The method of claim 2 further comprising:transmitting the signed challenge.
 7. The method of claim 6, whereintransmitting the signed challenge comprises: transmitting sound signalsrepresenting the signed challenge.
 8. (canceled)
 9. A token, comprising:means for receiving sound signals representing a challenge; and meansfor displaying a source of the challenge in human readable form.
 10. Thetoken of claim 9, further comprising: means for digitally signing thechallenge to render a signed challenge
 11. The token of claim 10,wherein the means for digitally signing the challenge uses a signingprocess that always renders the same signed challenge when presentedwith the same challenge.
 12. The token of claim 10, wherein the meansfor digitally signing the challenge comprises: means for combining, thechallenge with a private key.
 13. The token of claim 10, wherein themeans for digitally signing the challenge comprises: means for combiningthe challenge with a private key and with a PN; and means forsubsequently storing, the PN along with a correlation of the PN to thechallenge.
 14. The token of claim 10, further comprising: means fortransmitting the signed challenge.
 15. The token of claim 14, whereinthe means for transmitting the signed challenge comprises: means fortransmitting sound signals representing the signed challenge. 16.(canceled)
 17. A token comprising: a microprocessor configured toreceive sound signals representing challenge; a microprocessorconfigured to receive the challenge from the microphone; and a displayconfigured to display a source of the challenge in human readable form.18. The token of claim 17, wherein the microprocessor is configured todigitally sign the challenge to render a signed challenge
 19. The tokenof claim 18, further comprising: a data store configured to store aprivate key, wherein the microprocessor digitally signs the challenge bycombining the challenge with the private key.
 20. The token of claim 18,further comprising: a data store configured to store a private key; anda PN generator configured to generate a PN; wherein the microprocessordigitally signs the challenge by combining the challenge with theprivate key and with the PN; and wherein the data store stores the PNalong with a correlation of the PN to the challenge.
 21. The token ofclaim 18, further comprising: a speaker configured to transmit soundsignals representing the signed challenge.
 22. (canceled)
 23. Aprocessor for use in a token, the processor configured to control:receiving sound signals representing a challenge; and displaying asource of the challenge in human readable, form.
 24. The processor ofclaim 23, wherein the processor is further configured to control:digitally signing the challenge to render a signed challenge
 25. Theprocessor of claim 24, wherein the processor is further configured tocontrol: transmitting the signed challenge.
 26. The processor of claim25, wherein transmitting the signed challenge comprises: transmittingsound signals representing tire signed challenge.
 27. (canceled)
 28. Amethod for use in a user component comprising: generating a challenge,wherein the challenge includes a source of the challenge in humanreadable form; and transmitting the challenge a source of the challengein human readable form; and receiving an acoustic representation of asigned.
 29. (canceled)
 30. (canceled)
 31. The method of claim 28,wherein transmitting the challenge comprises: transmitting acousticrepresentation of the challenge.
 32. The method of claim 28, furthercomprising: using the signed challenge as an encryption key to encryptdata.
 33. The method of claim 32 further comprising: deleting the signedchallenge.
 34. The method of claim 28, further comprising: using thesigned challenge to decrypt data.
 35. The method of claim 34, furthercomprising: deleting the signed challenge.
 36. A user componentcomprising: means for generating a challenge, wherein the challengeincludes a source of the challenge in human readable form; and means fortransmitting the challenge a source of the challenge in human readableform; and means for receiving a signed challenge, the means forreceiving comprising a microphone configured to receive an acousticrepresentation of the signed challenge.
 37. (canceled)
 38. (canceled)39. The user component of claim 36, wherein means for transmitting thechallenge comprises: a speaker configured to transmit acousticrepresentation of the challenge.
 40. The user component of claim 36,further comprising: means for using the signed challenge as anencryption key to encrypt data.
 41. The user component of claim 40,further comprising: means for deleting the signed challenge.
 42. Theuser component of claim 36, further comprising: means for using thesigned challenge to decrypt data.
 43. The user component of claim 42,further comprising: means for deleting the signed challenge.
 44. Aprocessor for use in a user component, the processor configured tocontrol: generating a challenge, wherein the challenge includes a sourceof the challenge in human readable form; and transmitting the challengeby transmitting an acoustic representation of the challenge in humanreadable form.
 45. (canceled)
 46. The processor of claim 44, wherein theprocessor is further configured to control: using the signed challengeas an encryption key to encrypt data.
 47. The processor of claim 46,wherein the processor is further configured to control: deleting thesigned challenge.
 48. The processor of claim 44, wherein the processoris further configured to control: using the signed challenge to decryptdata.
 49. The processor of claim 48, wherein the processor is furtherconfigured to control: deleting the signed challenge.